Create Object API (Note/Article only for now) - #73

Converting the timestamp to Date can make Actor.objects skip rows. In PGlite, three objects with published = '2026-09-14T12:00:00.123456Z' produce one edge and hasNextPage: true for first: 1, then an empty page for the returned cursor. The Date conversion truncates the cursor timestamp to .123Z, so it no longer equals the stored value and the UUID tie-breaker cannot recover the remaining rows. The existing test uses millisecond-aligned dates and misses this case.

Could we preserve the database precision with Temporal.Instant? Drizzle ORM 1.0.0-beta.22 supports this through customType with fromDriver/toDriver; a PGlite round trip preserves the microseconds. Native Temporal support is tracked in drizzle-team/drizzle-orm#1776. The current composite cursor also preserves the ISO string, but its decoder returns a string, which the mapper needs to accept. The GraphQL DateTimeResolver rejects Temporal.Instant values and converts ISO strings back to Date, so it would need to change too. Please add a pagination regression test with microsecond timestamps. The full Temporal-to-GraphQL pagination path still needs verification.

postsCount counts objects that this outbox never returns. Creating a single FOLLOWERS object through the mutation yields totalItems: 1, but the outbox page has no items. Deleted objects are also excluded from the page query. The existing outbox test expects a count of 23 while returning only 21 items across its pages.

Please compute the outbox count with the same actor, deletion, and visibility filters as the page query. If we keep a cached count, it should count only objects matching those filters.

This filter hides deleted records only when they are the direct result of node or nodes. After marking an actor deleted, node(actorId) returns null, but node(objectId) { ... on Object { actor { uuid } } } still returns that actor. It also remains reachable through Instance.actors, and following its objects connection still returns content.

What should happen to an actor's objects when the actor is soft-deleted? The relation queries and their counts should follow that decision. The foreign key's ON DELETE CASCADE only handles physical deletion. Please add regression coverage for Object.actor, Instance.actors, and the deleted actor's objects connection alongside the direct node lookups.

visibility loses information that DrFed needs for debugging. Different combinations of to, cc, and audience can produce the same visibility label, so we cannot reconstruct the original addressing from this enum. The ActivityStreams audience-targeting model leaves much of its interpretation to implementations.

When Public is absent, Mastodon's initial classification checks for the author's followers collection in to, while Misskey checks both to and cc. A single stored enum cannot represent both interpretations.

Please preserve the addressing fields themselves. Visibility presets can still help users compose objects, but they should expand into explicit addressing before storage. The dashboard could show how Mastodon, Misskey, and other implementations would classify that addressing, with the implementation version and the reason for each result. I would compute those classifications in application code and expose the results through GraphQL, rather than store one implementation's interpretation as authoritative. The dashboard should label these as expected classifications, since actual access also depends on the receiving server's state and policies.

Could we model addressing targets and collections explicitly? The many-to-many relation should allow an object to address individual actors, collections, or unresolved IRIs. Restricting the target to a collection would exclude direct actor addressing: ActivityStreams defines to as an Object or Link reference. The Public collection is also special: it cannot receive deliveries.

One possible layout is:

The table names and how the data is split between them are suggestions. The same target appearing in both to and cc must remain distinguishable. Keep audience distinct from to and cc. An activity's addressing and its embedded object's addressing should also be stored separately.

Addressing a followers collection is distinct from enumerating its members. Membership can change, so replacing the collection reference with its current members would lose the original intent. Observed membership and actual delivery recipients belong in separate records if we need that history. For received documents, retaining the original JSON-LD alongside these queryable relations would also preserve details that normalization may discard.